NewEra - Abap Development Standards #Abapstandards

Introduction

This document contains the standards for development that is within or related to SAP R/3 at New Era Cap. These standards are to be followed by all developers in this environment, whether permanent associates, long-term contractors, or temporary consultants.
This document is organized first by development object (ABAP, Batch Job, etc.), and then by development components. The main four components are:

• Documentation Standards
• Naming Standards
• Best Practices
• Templates

These apply to nearly every object type. Other components are covered for objects where they are deemed applicable by the Standards Committee.

Implementation policy

This document pertains to all future development. That is to say that existing development is not required to meet the standards at this time. However, when a developer modifies an existing development object, they should consider updating the entire object to meet the standards. Whether or not to update the entire object is at the discretion of the developer or analyst, and should be determined based on the time, effort and value of bringing the object into compliance.
This document must be distributed to all developers in ECC 6.0 or related systems at NEC. New developers/consultants should be given this document when (or before) they receive their SAP access.

ABAP Naming Standards

Programs

SAP allows ABAP names up to 40 characters in length. Program names can contain letters, numbers, underscores (_), etc. Program names may not contain spaces ( ), plus signs (+) or asterisks (*)
Programs beginning with a “Z” or “Y” are considered to be in the customer namespace. This prevents SAP from overwriting or altering the program during upgrades or hotpack installations. At this time, NEC does not use the “Y” namespace. All NEC development should start with “Z”.

New development

The first 8 characters of the program name must be a unique identifier of the program. This facilitates program identification in, for example, report headers. The remaining 32 characters may be used to describe the program’s purpose.
The name should follow this format: ZTAA_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, where:

• Z – literal “Z” which starts all NEC programs
• T – the program type, as follows:
  • C Conversion – is used for one-time data imports from a legacy system (NOT an interface)
  • E Enhancement – enhances or expands SAP functionality, such as a User Exit
  • I Inbound interface – is run repeatedly, to import data from an external system.
  • N Include member – cannot be executed directly, but is called by other programs
  • O Outbound interface – is run repeatedly, to export data to an external system
  • P Update/Process – performs a database update or a process
  • R Report – reads and examines data, but does not update (this code is frequently used)
  • U Utility – performs system maintenance functions (informational or update)
• AA – a two-letter code for the Business Application Component. For Eg. If the development is for SD Module then it should be SD or MM for Material Management
• XXX… – a meaningful description of the program’s purpose.

EXAMPLE:

ZISD_BI_SELL_THROUGH follows both the SAP & NEC standards. Here I stands for Interface, SD stands for Sales and Distribution module , BI indicates it is related to BI and Sell Through project.

Copies of SAP programs

When copying a standard SAP program, the same name should be used for the copy, but insert a “Z” at front of the program name to identify it as a customer program. For example, standard check printing program RFFOUS_C is copied to ZRFFOUS_C, NEC changes are then made in ZRFFOUS_C.

Function Modules

A function module can have any name, up to 30 characters. It must be unique within the Function Builder and can consist only of alphanumeric characters and the underscore “_”.
All NEC created function modules should begin with “Z_”. The remaining 28 characters should be used to describe the functionality as much as possible.
Example: Z_DETERMINE_BOL – Function Module to determine the Bill of Lading.

Variables

A field name can be up to 30 characters long, and may contain any alpha numeric character or symbol apart from the special characters “'( ) + . , :”. However, a name may not consist only of digits. SPACE is a reserved name, and may not be used.
Data field names are freely definable but they must be prefixed appropriately. Use the following prefixes:

• z Data fields
• s_ Select-options
• p_ Parameter
• c_ Constants
• t_ Internal tables

After the prefix, it is preferred to use the same names as SAP standard fields (e.g. p_matnr, zkunnr, c_vkorg).
When changing an SAP standard program (or a copy of one), all new variables must start with “z”. (The exception to this when implementing an OSS note. Then use the variables as written in the note.)

Subroutines (Forms)

Subroutine names should be descriptive of the main purpose of the subroutine. The format of the names should be consistent throughout the program, including whether the words are separated by an underscore "_" or by a hyphen "-".
It is preferred to prefix the subroutine name with "F###", where ### is a four-digit number (e.g. "F1000"). This provides unique identification, and helps with keeping subroutines in a standard order.

Documentation Standards

Programs must be thoroughly documented both internally and externally. This is necessary to facilitate maintenance of programs and expansion of the R/3 footprint.
Documentation should be thorough and understandable by non-programmers..
If the programmer cannot write detailed documentation in English, they may use their primary language, but a brief explanation must be included in English, regarding the main purpose and major functions of the development. It is preferred for the developer to work with a translator to write comments in English.

Internal

Program Attributes

The Program Title (on the Attributes screen) must be maintained to describe the purpose of the program.

Program Header

All ABAP program code must begin with the standard header comments. This must be kept up-to-date as modifications are made to the program.

EXAMPLE:



In the above example, items in italics should be replaced with information relevant to the development.
When changes are made to a program, they must be added to the Modifications section of the program header. This will include the Transport Number, Date, Programmer, Recap Number & Description, as shown above. The version number must be in the format “Recap#”, which will be included at the end of all changed code lines.

Inline documentation

Programs must contain explanatory comments throughout the code. Comments should be thorough enough that a non-programmer could understand the program’s parts & functions.
For code modifications, the Version Number must be added at the end of each added/changed line ( e.g. "Recap # 90001 ). This number can then be referenced to the Modifications section for details/explanation of the change.

External

Specifications Document

External documentation for new developments must include the Development Specifications document. This document contains both the functional and technical specifications, as well as documentation of changes throughout the lifecycle of the program.
When making modifications to an existing ABAP, the original Specifications Document should be appended noting the changes. If that document does not exist, a new one should be started, documenting the main purpose of the program, and the changes that were made. It is not required to write the specifications for the original development at this time.

Best Practices

Source Code Content

• Do not hardcode text or values, if at all possible. Use Text elements, Parameters or Constants instead.

Source Code Layout

• Format should be clean & easy to read.
• Comments should be clear & frequent.
• Use consistent indenting within ABAP statements (LOOP, IF, CASE, SELECT, etc.). This is intended to make the program easy to read and understood by people other than the original programmer.
  Program  Pretty Printer can be used to set appropriate formatting.
• Use inline comments to explain the name or purpose of all DATA, TABLE and INCLUDE items.

• In each grouping of similar keywords, line up the similar arguments. This helps make the program more easily readable. In the following example, the Type attributes are aligned, although the variable names have varying lengths.

• Use colons ( : ) to use a keyword multiple times. Everything before the colon is repeated at each comma. Don’t get carried away, this can also make things harder to read.

Modularization

Programs should make use of Form subroutines, includes, and function modules wherever possible to reuse code, and for improved readability.
Use START-OF-SELECTION and END-OF-SELECTION to define the main processing area of a program. Form routines should be used as much as reasonably possible so that the program is organized into functional sections (e.g. GET DATA, PROCESS DATA, UPDATE DATABASE, WRITE RESULTS).

Optimization

Optimization Tools

• Use SQL Trace (ST05) to analyze overall efficiency of Select Statements.
• Use the Runtime Analysis (SE30) to find the least efficient areas of a program.
• Use the Tips & Tricks section of Runtime Analysis (SE30) to compare performance of code snippets.

Selects and Joins

• Try to avoid a SELECT within a loop.
• Structure the WHERE clause of a SELECT statement so that it uses as many relative key fields as possible and (if feasible) test it several different ways. The number and organization of the fields may effect whether it uses an Index and if it uses the right one. Results can be viewed and compared via the SQL Trace.
  
  Note: Selecting a large number of records via the wrong Index can decrease efficiencies.
• Always try to limit the number of records retrieved by a SELECT statement, especially against the larger tables. Using reference tables can be an efficient way to do this:
• SELECT…WHERE IN is usually the most efficient way of retrieving a large amount of information.
• If WHERE IN cannot be used, try SELECT…FOR ALL ENTRIES IN…, but be certain to check that the reference table is not empty. If it's empty, that translates as “no restrictions”, so you’ll get everything from the SELECT table.
• Reduce the size of a reference table (wherever possible) used in WHERE IN or FOR ALL ENTRIES IN clauses. Sort the reference table by the primary key of the SELECT table and then use DELETE ADJACENT DUPLICATES against the reference table, prior to performing the SELECT.
• Create a pseudo selection-screen table with a set of reduced selection criteria if possible. When using this, use I/EQ, rather than any other range definition method.
• If a pseudo selection-screen table is used in a SELECT…WHERE IN, be sure to:
  (1) ensure that the pseudo selection-screen table is not empty at the time of the SELECT;
  (2) ensure that the number of entries in the table is less than or equal to 2550; otherwise perform a SELECT…FOR ALL ENTRIES IN.
• Avoid “SELECT * ” statements against tables with many fields. Use specific field names and INTO TABLE or INTO CORRESPONDING FIELDS OF wherever possible.
• Do not attempt to join more than three or four related tables at a time.
• When doing an INNER JOIN on tables, attempt to structure the statement so that it is a Many-to-One. For example: get the order item data using “FROM VBAP” and then join the order header with “INNER JOIN VBAK”.
• When doing an INNER JOIN on tables make sure that the fields that you are attempting to do the join on have the same format.
  
  The example shown below will not generate any errors during Program Check or Program Generation. However, EKPO-EBELP is length 5, and VBFA-POSNN is length 6. Therefore their values will never be equal, and no data will be returned.

EXAMPLE of INCORRECT usage:
SELECT ... FROM VBFA
INNER JOIN EKPO ON EKPO-EBELN = VBFA-VBELN
EKPO-EBELP = VBFA-POSNN

• Use CLEAR & REFRESH on internal tables as soon as information is no longer required from them (prior to program completion) to release the storage back to the system.

Nested Loops

• Avoid Nested Loops (loop-within-a-loop) if at all possible!
• If a Nested Loop is unavoidable, use an Index with the inner loop.
• An alternative to Nested Loops is to sort both tables by the comparison field(s), LOOP against the first table, and READ…WITH KEY…BINARY SEARCH against the 2nd table.
  
  This works as a place-holder in the 2nd table, rather than re-reading the 2nd table every time. For this to work it is critical that the two tables are sorted in the same order before initiating the LOOP/READ TABLE processing.
• When using several LOOP/READ combinations, with the same READ table, insert the statement READ TABLE…INDEX 1 between LOOP statements. This resets the READ placeholder to top of the table.
• When re-READing a table, insert a CLEAR statement prior to the subsequent READ. This removes leftover data from the previous READ.

EXAMPLE:

Copying SAP programs

When enhancing standard SAP programs, copy them if at all possible. Direct changes to non-Z programs may be lost during hotpack installations or upgrades.
When copying a standard SAP program, the same name should be used for the copy, but insert a “Z” at front of the program name to identify it as a customer program.
New variables added to a copied program must start with “z”.

Variants

Variants allow consistent execution of programs. They may be created by any user executing a program. Obsolete variants should be deleted.

Variant attributes

• Only For Background Processing – disallows use of a variant in foreground processing. This should not be used except to protect a background variant from changes.
• Protect Variant – allows anyone to use the variant, but only the user that created a variant can change it. This can be used as needed, but is not recommended as the default. Terminated users have to be re-activated to change a variant with this setting.
• Only Display In Catalog – variants don’t appear in the drop-down list, but in Variant Catalog (accessible through SE38). This is not normally used, but can help t protect variants used in background processing.
• Selection Variable (Dynamic date formatting) – Variants used for background jobs commonly need the dates to stay current with the program run date. Use this function to make the dates dynamic.
  On the Variant Attributes screen, click the check box next to the date field in the Sel. Variable column, then click the Selection Variables button. Next click the blue down-arrow to the right of the Variable Name field to get the list of options.
  
  This function is only available for date fields.
  
  

Program Attributes

Text Elements

ABAP Text Elements can be used wherever a constant value is needed. They are one method of avoiding hard-coding, but have the added advantage of being language-specific. Any program that may be executed in multiple languages should use them.
Text elements are a separate transport object from the program source code. Be sure they are included in any transports. They often get missed due to multiple changes to a development going to QAS, and only the last one being moved to PRD. Either move ALL transports into PRD (in order), or add the text to the last one by faking a change, or manually modifying the transport request.

Headings

For reports, prepare the headings by running the report (after saving the ABAP), and then use SystemListHeader to enter the headings in the appropriate place. This will then be saved to the HEADINGS texts. Be sure to create a translated version as well.

Tips & Tricks

• Check sy-subrc after every SELECT, LOOP or READ statement. Don't assume records were found.
• Whenever programming a function that seems commonly useful, look for a Function Module to do it for you.
• Use CLEAR…WITH… to fill a variable with a single character.
• Use TRANSLATE…USING… to replace one character with another in a field.
• Always check for division by zero.
• Use functions “UPLOAD” and “DOWNLOAD” to get & put files on your local PC/network drives.
• Inserting a line containing only “*eject” will force a page break when the program code is printed. Use as appropriate for readability.

Pseudo selection-screen table

• ** It is sometimes useful to define a pseudo selection-screen field that mimics a SELECT-OPTIONS field. The following example shows this for Sales Order Document Number.
  
  
  
  

Templates

Data Dictionary

Transparent Tables

Naming

Table names for NEC’s-developed tables should start with ‘Z’ and should be followed with meaningful name.
SAP allows for up to 60 characters for the table description. Use as many characters as necessary to provide a meaningful description of the table.

Best Practices

Table Maintenance in SAP R/3

Only authorized Application Developers can create new tables in SAP R/3. All new tables must be reviewed and approved by the Database Administrator (DBA) before being created. The DBA must always review data storage parameters, complex database operations such as table conversions, and any data dictionary changes impacting performance enhancements.

Delivery Class

Select the appropriate Delivery Class according to who is responsible for maintaining the table contents and how the table behaves in a client copy or upgrade.

Table Maintenance Allowed

The “Table Maintenance Allowed” checkbox should be left unchecked.

Technical Settings

The Data class should be USER.
The size category should reflect the expected number of records in the table. The data class and size category determines the storage area to be selected in the database and the expected table size. Correctly assigning a size category prevents over- and under-allocation of database extents.
Choose the status “Buffering not allowed”.
Leave the “Log data changes” checkbox unchecked.

Primary Key/Index Assignment

Primary key accessed fields should be defined as the first fields of the table. Indexes should not be defined unless the table is very large and cannot be accessed via key fields.

IMG Tables (Condition Tables, Reporting Information System Tables, etc.)

Follow the SAP Online Help instructions when creating tables within the IMG. Consult the Database Administrator before activating tables or structures in any of the Reporting Information Systems, (e.g., LIS, SIS, PIS, etc.).
Business Warehouse development will require reevaluation of this standard.

Templates

The following template programs should be used to load, display, and update data in custom-developed tables:

• Sample program for a table load from a spreadsheet – ZRSD0082
• Sample program for a table display program – ZRMM0031
• Sample program for a table update program – ZRMM0032

Fields

Naming

Field names can be up to eight characters in length, and contain only letters or numbers.
The standard SAP field names should be used if possible, such as MATNR, WERKS, etc. If non-standard fields are required the names should be as descriptive as possible.
Fields (unlike data elements) are specific to the structure in which they exist, and so naming is determined based on where the field is being created:

• Fields in Customer-developed tables (Z-tables) may have any name, but it is preferred to use the same names as SAP standard fields.
• MATNR for material numbers
• MNAME for a person’s middle name
• Fields added to SAP Standard tables or structures must contain a “Z” in the first position, to differentiate them from the original fields. It is preferred to use the same names as SAP standard fields.
• ZMATNR for material numbers
• ZMNAME for a person’s middle name

Documentation

Not applicable.

Best Practices

Not applicable.

Views

Naming

View names can be up to ten characters in length. The first two characters must be “V_”. The remaining eight characters should be the table name. If more than one table is incorporated in the view, use a meaningful combination of the table names.
Position definitions for data dictionary views: V_UUUUUUUU

• V_ – system constant
• UUUUUUUU – Table Name or a meaningful description

Documentation

Not applicable.

Best Practices

Not applicable.

Structures

Naming

The structure name should start with ‘Z’ and should be meaning full

Data Elements

Naming

The data element name should always start with ‘Z’.
The Short Text should more fully describe the meaning of the data element, which will be copied to associated Fields.

Best Practices

Field Labels

Create appropriate abbreviations for the short, medium, and long field labels.
The heading length should correspond to the display length of the field and contain an appropriate abbreviation.

Domains

Naming

The domain name can be up to eight characters in length. The first character must be “Z” for customer-specific domains. The remaining characters should be as descriptive as possible. If the technical attributes of the field are the same as an existing field, use the existing domain name.

Best Practices

Use of Value Tables

The value set of a domain can be determined by specifying a value table.
All table fields, which refer to this domain, can then be checked against the corresponding field in the value table. In order that the check can be executed on the input template, a foreign key must be defined for the value table.
The value set defined by specifying a value table can be further limited by allowing only a subset of the values in the value table. This subset can be determined by specifying a check table, which is itself connected to the value table via foreign keys.
A table can only be the value table of (at most) one domain. All fields that refer to the value set of this table must use the same domain.

Maintenance and Dependent Objects
When you change a domain, all tables having a field that refers to this domain must be activated again. Re-activation is automatically triggered when the domain is activated, thus ensuring that all these tables are adjusted to the changed technical field information.

SAPScript

Naming Standards

The name of a layout set has a maximum length of 16 characters and can include upper case letters, numeric characters, hyphens “-” and underscores “_”. It must begin with a letter.
All NEC layout sets must start with the letter “Z”. After the first character, the name is freely definable.

New development

For new development, the name (after the “Z”) is at the discretion of the developer. It should describe the purpose of the SAPScript.
EXAMPLES:

Copies of SAP Standard SAPScripts and ABAP

Most often, SAPScript development starts as a copy of a standard SAP layout set (the original SAP layout set should not be changed). In this case, the same name should be used, but with a “Z” inserted in the first position.
Multiple versions of a SAPScript (e.g. Invoices that use different layouts) should have similar names, differentiated using numbers or letters.

Windows

Layout set windows should have a name which reflects the purpose of the data to be displayed in the window. For example: ADDRESS for an address window, HEADER for a letter header, etc.
The description should further identify the usage of the window.

Paragraph and Character Formats

Paragraph and Character Formats are identified by a two-character name. The name may be comprised of letters, numbers, underscore and hyphen, but must begin with a letter.
The description should identify the usage of the format.

Best Practices

Multi-lingual development

SAPScripts are intended to support multi-language implementations. Pages, windows, and formats are defined in the original language of a SAPScript, but Text elements (the contents of a Window) are definable for each language version. This functionality should be used wherever possible. A separate SAPScript is required to change Window placement or Page Layout.
A SAPScript normally executes in the language of the recipient (vendor, plant, customer), but this can be controlled using the SET LANGUAGE statement in the associated ABAP.

Identifying TEST output

It is easily possible that non-production output (tests) can be printed to Production printers. In order to avoid confusion, all SAPScripts must contain the following Window. It must be placed on all pages of the output, in a clearly legible position.
This window prints a large graphic “TEST” and a text comment (&TEXT-001&) whenever the system is not Production Client 410. Note that text-only printers (dot matrix) will not print the graphic “TEST”, so placement of the text comment becomes vitally important.
The ABAP text element (TEXT-001 in this example, though that may be changed) MUST be maintained in any language the SAPScript may be output. It should say something like “Do not send – Test output – Do not pay”, depending on the purpose of the output.

Loading graphics with RSTXLDMC

Use program RSTXLDMC to load graphics (black & white or grayscale). They are saved as a Standard Text, and then INCLUDED into a Text Element. The source must be a grayscale or B&W TIFF 6.0 file.
All graphics are actually black/white. The maximum resolution is 600 dpi, to force compliance with the greatest range of output devices. In order to simulate grayscale, SAP increases the size of the image to effectively increase the detail while staying within the allowed resolution.
To adjust the appearance of gray levels in a graphic, use these fields: Type, Resolution for TIFF file, and No. of TIFF gray levels:

• TYPE – use BMON or PCL. BMON is straight black/white, PCL allows shades of gray
• No. levels – This field is ignored unless TYPE is PCL. It may contain the values 2, 4 or 9.
• 2 – the same as Black and White. (Multiplies resolution by 1)
• 4 – adds 2 levels of gray, and doubles the image size. (Multiplies resolution by 2)
• 9 – adds 7 levels of gray, and triples the image size. (Multiplies resolution by 3)
• Resolution – The number entered in this field is multiplied by a factor related to the number of gray levels (as shown above). Since the allowed resolutions are 75, 100, 150, 200, 300, 600, and no decimals are allowed, only certain combinations are possible.

Windows

Separating graphics from text

For SAPScripts with boxes, shading, and standard labels, create separate windows for these items vs. the data. For example, an Address box may have an outline and be labeled “SHIP TO:”. These should be in a window separate from the address itself, although they are in the same position on the page. This allows much easier maintenance & control of the data and graphics.

Header information

The Description of a SAPScript must be updated to describe its purpose. This is easy to forget when copying an existing SAPScript, which makes it difficult to find/maintain them later.
The Status field reflects the current status of the SAPScript. It must be “Active – Saved” for the Script to work. Activate a SAPScript from change mode using FormActivate.

Using Text Elements

Window text elements may be controlled using a Write statement in the associated ABAP program. This controls when the ABAP orders the window to print. Text elements may be identified with “/E” in the tag column. These elements must be called explicitly in a Write statement, or they will not print at all. Elements without “/E”, or before the first “/E” in the window will print at the Close Form statement.

Key words

SET DATE MASK – Use with an ABAP Text Element (&TEXT-001&) to format dates according to the output language. This command can be placed at the top of every SAPScript element where a date is printed, to be sure they all have the same format.
SET COUNTRY – This command can be placed at the top of every SAPScript element where an address is printed, to be sure they all have the same format.
ADDRESS – Use this command wherever possible for address printing. SAP formats addresses according to the legal requirements of each country.
CASE / WHEN / ENDCASE – Use in place of IF / ELSEIF / ELSE / ENDIF, where possible.
PERFORM / ENDPERFORM – May be used to perform calculations within the SAPScript.
DEFINE – Use to define constants as needed.

Default paragraph formats

A default Paragraph Format may be set for each window. Then any line in the Text Element with “*” in the tag column will use this format.
Note that INCLUDED texts are usually created using “*”, but it is possible for them to use something else. This could cause problems with printing the output.

ABAP Text Elements

SAPScript can use the language-dependent ABAP texts, by inserting them as variables in the Text Element (e.g. &TEXT-001&). They will appear in the language with which the SAPScript is being output.
A useful example of this is date formatting. In the ABAP Editor, create text element TEXT-001. In English, give it the value “MM/DD/YYYY”. Using the Translation feature, enter the Spanish translation “DD-MM-YYYY”. Then use it in the SAPScript: SET DATE MASK = &TEXT-001&. Now the printed dates in the SAPScript will be formatted appropriately for the language. Note that the Month-first format uses slashes (/) for separators, but the Day-first format uses hyphens (-). This is the standard for all NEC development.

Choosing and using text editors

Two text editors are provided in R/3 version 4.5B: the Line editor and the Graphical editor. Change between the two from the SAPScript Text Element screen, using GotoChange Editor. Switch your default editor using GotoConfigure Editor.

The Line editor gives visibility to all formatting commands, and should be used for making changes to Text Elements.
The Graphical editor displays text in the way it will be output. This can be useful for verifying formatting, but is not suggested for editing.

Templates

Use existing SAPScripts as examples for creating new ones.
In the SAPScript editor, go to Application Help for SAP’s online documentation. This contains thorough instructions for keywords, etc.

Interfaces

SAP recommends and supports three methods of interfacing data:

• IDoc – Intermediate Document
• BAPI – Business Application Programming Interface
• BDC – Batch Input Sessions

The preferred method at NEC for a batch interface (inbound and outbound) is to use an IDoc . If an IDoc is not available from SAP, a custom IDoc may be developed in some instances.
If an IDoc interface is not feasible, then BAPI and BDC solutions should be explored. Currently, there are several BDC interfaces implemented in the production environment. The BAPI interface option has not been implemented for any interface solution.

Transport Requests

Naming

The transport description should always starts with Recap Number followed by Module and description of the task

Development Class

When ever a new Object is created, a development class should be assigned in the attrivutes of the object according the business requirement.
For E.g, If the object is related to Sales and Distribution module then the development class is ZSD or if it is related to FI then it is ZFI. If the object belongs to cross module or developer is not sure of the business requirement then they can use development class Z001.

Development Class/Domain	Description
Z001	Customer development class
ZBC	Basis Components (New Era)
ZBI	Development Class for BI
ZCA	Cross Application (New Era)
ZCAC_POSTGO_REPS	Extract data for validation
ZCO	Controlling (New Era)
ZEDI	New Era: EDI and IDoc Interface Development
ZEDI_DEV	New Era: EDI and IDoc Interface Development (NEQ.100)
ZFI	Finances (New Era)
ZMEI	Delego Credit Card Software Utilities
ZMM	Materials Management (New Era)
ZMM_CONV_UPC	Updates UPC of ZNE_MATL_CONV PS Materials
ZMM_EXTRACT	MM Extract and Dump
ZMM_PGL	MM Post Go-Live.
ZMM_Q200	Q200 Upload Reports
ZMSBI	Microsoft Business Intelligence Applications
ZNE_CAC_001	CASCANTE 001
ZNEC_ECC_DEV	NEC-SNC ECC development package
ZPANAYA	ZPANAYA
ZPH_CHECK	Report to search Product Hiearchy entries
ZPP	Production Planning (New Era)
ZQWK	Metamor Quickwear standard package
ZROAL	ROAL-related jobs/interface requirements
ZSD	Sales and Distribution (New Era)
ZSD_COND	Authorization Check for the condition screen
ZSD_DEV	New Era: Sales and Distribution Custom Developments
ZWM	Package for Warehouse Management (NewEra)
ZXX	Miscellaneous - Undefined (New Era)

Appendix

Reference Materials

Business Application Components

Business Application Components are SAP-defined development areas of SAP R/3. All new developments should be associated with a Component in order to identify the affected areas of R/3, and to determine responsibility. Frequently these codes are referenced in the name of the development, but also should be used in documentation or discussion of these components.
These abbreviations are defined by SAP, and a complete list can be found at ToolsABAP Workbench, OverviewApplication Hierarchy (SE81).
The codes listed below are a subset of the Application Hierarchy list. These codes are the only ones currently to be used at NEC. If none of these codes is applicable, contact the Standards team before using a code not listed here. In choosing the correct Component, it may help to review the Sub-Components (below) and then select the associated Application Component.
Logistics:

• LO Logistics (General) – use where the other active Logistics components do not apply
• MM Materials Management
• SD Sales & Distribution
• PP Production Planning

Accounting:

• AC Accounting (General) – use where the other active Accounting components do not apply
• FI Financial Accounting
• CO Controlling
• EC Enterprise Controlling